There is increasing interest in moving control and intelligence from individual switching, routing, and bridging network nodes to a fewer number of controller nodes. Such networking architectures will be referred to herein generally as centralized control plane networking architectures (CCPNAs) and are exemplified, for example, by a software-defined network (SDN). An SDN is one example of a network architecture wherein a forwarding plane (sometimes referred to as a data plane) and a control plane, which are conventionally implemented in a single network node, are separated and implemented in two distinct network nodes. Such distinct network nodes may be referred to as a datapath node and a controller node, respectively. An example of an SDN architecture, or specification, is the OpenFlow Switch Specification, version 1.4(OpenFlow).
Theoretically, by separating the forwarding function and the control function into different network nodes, multiple relatively inexpensive datapath nodes may be coupled together and controlled by a single controller node, resulting in a lower overall network cost. Another potential advantage of a CCPNA is that a single controller node can be more easily programmed to implement new network functionality than would be possible by programming multiple conventional network nodes that combine the control plane and the forwarding plane, thereby simplifying the implementation of additional networking functions in the network.
When a new flow between a source node and a destination node is originated in a CCPNA, an ingress datapath node typically informs the controller node about the new flow so that a path through the network may be determined. The controller node determines an appropriate path through the network, and the controller node then sends packet-forwarding commands to the datapath nodes in the path so that each datapath node can install a flow entry into a flow table that pertains to the new flow, and indicates where packets associated with the new flow are to be forwarded. This path setup process takes time, relatively substantial controller node processing, and network bandwidth, but provides high-granularity routing through the network.
In some environments however, such as a service provider environment, the number of new flows that are continually initiated may be prohibitive to setup individually. To solve this problem, the datapath nodes may utilize one or more wildcard, sometimes referred to as aggregate, flow entries that group, or aggregate, what could be identified as many separate flows into a single flow entry. For example, an aggregate flow entry may direct that any flow initiated from any media access control (MAC) address, and/or which are destined for any MAC address, be forwarded through a certain port of the datapath node, without a need to communicate with the controller node.
Aggregate flow entries thus reduce communications between an ingress datapath node and a controller node and reduce the processing requirements of the controller node, but at a loss of flow granularity. The loss of flow granularity can be undesirable however, for other purposes, such as when measuring certain path characteristics, such as, by way of non-limiting example, path continuity between two datapath nodes. Determining path continuity between two datapath nodes may become difficult or impossible at a desired level of granularity when multiple independent flows are aggregated together. For example, because each datapath node in a network may have different aggregate flow entries, as well as different non-aggregate flow entries, some flows that are part of an aggregate flow at an ingress datapath node may be split off from the aggregate flow prior to an aggregate flow entry at an egress datapath node, rendering it difficult or impossible to determine continuity between any two specific datapath nodes.
One solution to this problem is an active measurement mechanism that injects trains of probe packets between two specified datapath nodes. However, such active measurement mechanisms increase traffic on the network, and require that at least some of the datapath nodes include active measurement functionality.
Another solution actively examines flow tables of datapath nodes on a continuous basis. However, this may substantially increase controller node overhead.